I am trying to understand AdventureWorks Database as most of the good examples on web and books are usually explained taking it as a sample database.
I found few links like
http://msdn.microsoft.com/en-us/library/ms124825(v=sql.100).aspx
http://merc.tv/img/fig/AdventureWorks2008_Conceptual.pdf
http://merc.tv/img/fig/AdventureWorks2008.gif
But I found them insufficient for explaining the business completely.
I tried to practice some queries as well so that I could get more knowledge about its business. But looking at 70 tables, I finds myself no were in the understanding of its Business.
Can you help me giving some good likes where I can get more details about it.
EDIT
I never read northwind database. Is it important to understand it to get a good grasp on AdventureWorks2008
Looking into what you are doing, I think it is not important for you to fully understand the AW business. If would be a better use of your time to understand the queries that are required and just the 2-3 tables in question rather than the entire database.
Even thought the MSTS certification book pulls from the AW DB, understanding that database is not part of the certification. If you have trouble with specific questions from your book, I would suggest you post what you are doing and what result you are trying to achieve.
I can go on explaining the business of AW but it will consume a lot of time as I cannot completely give the business understanding. You will only understand those things that I will describe here. I am currently going through this book- The Microsoft Datawarehouse Toolkit by Ralph Kimball. This is the best book that will give you a detailed understanding of AW business.
The business requirements ranges from a variety of people. From sales to technical people and others. So I suggest you read the first 3 chapters of this book as it simplifies learning the business.
If reading is not feasible I will show you another approach:
AdventureWorks (AW) is an imaginary manufacturer and seller of bicycles and its accessories (Table Production.ProductCategory).
The schemas help a lot in understanding their business, sales, employee data and product info.
The schemas involved in AW database are: HumanResources, Person, Production, Purchasing, Sales.
The table names are self-explanatory to a great extent. A simple query against each table will give you a fair amount of information about data.
You can go through this link that gives a brief overview of schemas used in AW
https://technet.microsoft.com/en-us/library/ms124894(v=sql.100).aspx
Think of yourself an interviewer and then frame questions that you will be asking the officers/managers of AW. Trust me there are lot of pitfalls if you are a newbie. Like, if you ask the question to business: "What do you want in your datawarehouse?" WRONG. This is your job to figure out.
All the best with exploration.
I have found this link below which if you follow the link depending on which sample database you are interested, it explains what it is all about:
https://msdn.microsoft.com/en-us/library/ms124501(v=sql.100).aspx
I have also fouund this ETL (but could not find for other databases):
http://msftdbprodsamples.codeplex.com/wikipage?title=%20AdventureWorksLTDiagram&referringTitle=AWSchemaDiag
I have also found these exercises:
http://sqlzoo.net/wiki/AdventureWorks
Related
I have a business team asking me about setting up a meeting to explain them about database design considerations. Since they do not have much idea on RDMS I'm to thinking to explain below things
What is RDBMS
What is a table and what are constraints / why we need them
What is a transaction and what are ACID Properties
Things to consider before/while developing a dbms
a. Decide how much detail you need and how much you may in need future
b. Identify fields with unique values
c. Select the appropriate data types for your fields
d. Normalization and Index design
Also most of the time this team has their data coming in from flat files which we need to load into the DB and represent into the format they need. Anybody please suggest what can i explain more or any better way I can explain. And kind of their data is all over the place. I just want to emphazise more on thinking it through because we couldn't set up a stable process to do the import. Any suggestion for me is welcome as well :)
Appreciate your help!
You haven't said what your audience expects to take away from your presentation. So I'll have to guess, based on my dealings with business people in the past. Your mileage may vary.
Business people typically don't care about the skills and knowledge you put into doing a good job with database design, even when they say they do. They want to understand database design in terms of costs and benefits. That is how business people think.
So if you must cover some technical topic like indexing, do so from a cost benefit point of view. There is a cost to adding an index to a table, and there is a benefit to adding an index to a table. Figuring out in advance whether the benefit is worth the cost is the really tricky part, and they will be interested in this.
On a larger scale, data is a business asset. There is a cost to managing that asset well, and there is a benefit to managing that asset well. If you can connect your talk to these two concepts, they will be interested.
If they are really good business people, they will have a good understanding of the subject matter that the database covers, provided it's a part of the enterprise data that affects their business. If you have a good ER model of the data in the database, this model will connect every value in every table to an attribute, and every attribute will describe some aspect of the subject matter. This is a very different use of an ER model than just using it as a preliminary to creating a relational model.
Technical people tend to think of ER modeling as "relational modeling light". It's really much deeper than that. It's an analytical handle on the question "what does the data really mean?" And this is a handle on "what is the data really worth?". And this is where the technical world meets the business world.
How about starting from the basis of CRUD operations, then move on to normalization, give the scenarios for the need of Normalization and concept of Keys in RDBMS ,then you can talk about the ER modeling
Considering the fact that you are presenting to business folks, I think there would be 2 approaches best suited to your needs.
a) WHEN YOU HAVE LESS TIME:
Only cover topics which need minimum or no prior knowledge. Cover RDMS & things to consider.
Keep it simple and easy to understand. Tell them how your solution works and why it is an effective one.
Cover only topics which are relevant and make it layman friendly. Provide them the pros & cons of your DB design. Connect it to business needs.
In all cases, provide contextual examples which they may relate to with ease.
b) WHEN YOU HAVE MORE TIME
You may cover topics in detail as suggested in the previous comments. (#SQL_Underworld & #Ramya)
I'm a university student who is completely new to SQL and I don't know what I'm doing, so go easy on me. I have been given an assignment to design a Facebook-like database for a website for people who read books. I have made a very basic data dictionary which gives the general idea.
Is this a valid approach? Is there a better way of doing this? I'd appreciate any feedback I can get.
First of all, I would say good to see your efforts.
Here I would suggests you bit enhancements. Instead of maintaining different tables for
books_liked,books_read,wish_list, etc., you can maintain same with the help of flags in the master table books. This is to normalize your data.
eg. flg_liked, flg_wish_list, flg_read
I've been looking at Microsoft's Adventure Works 2012 database. I'd be very interested if there's any information explaining why the tables were created as they are. Some sort of schema overview I guess.
For example:
Why they chose to create a BusinessEntity table as a sort of base class for Person, Employee, etc.
Most of the data is normalized so why they chose to put the CountryRegionCode field into the StateProvince table instead of an ID to a separate table.
Anyway I'm very interested in learning more about the decisions that went into the databases design. Anyone know a resource that goes into this sort of thing?
I am not aware of any official design documentation for AdventureWorks, but I use to be a trainer and used AdventureWorks databases extensively for demos and labs, so I am pretty familiar with it.
The BusinessEntity table is a classic case of a SuperType/SubType design, which reduces data redundancy, because customers could also become vendors, employees could become customers, and every other combination. Also, it means that you are not storing details related to all entities repeatedly, in separate tables, minimising effort in the event of code changes.
The CountryRegionCode I am not positive about, but I would suspect one of three reasons:
There are not enough distinct combinations to warrant an additional table at the expense of reporting performance (This could be validated with some simple COUNT(*) GROUP BY statements)
They wanted it in the same table so that in future they had the flexibility to model a hierarchy structure with hierarchyID (This is the least likeley option)
It was a normalisation error! (My money is on this option!)
This image helped me, even though it's technically for 2008.
Here is a link to fill in with a bit on the background:
https://technet.microsoft.com/en-us/library/ms124825(v=sql.100).aspx
I asked the following question on a database site:
I am trying to build an EER Model for a Autostore that has 5 locations
and offers a range of auto products. They offer car repairs and
roadworthy tests as a service also. I need to be able to make
fortnightly reports on unfinished service jobs, and fortnightly
reports on the sales. They have a wide customer database filled with
full addresses. There is a constant inflow of new stock items and
restocking of old ones. There should also be a way to know the cost of
each item in stock and where its being held.
I swear I've researched it enough to be able to understand it by now
but Im really struggling to map this out as I'm constantly running
into a wall when dealing with the products that are being restocked,
sold and stocked by particular stores in different locations.
-I'm a total rookie with this kind of thing but if anyone can help me it would be amazing.
but I am struggling to find an answer and was thinking that maybe if I asked someone here to build an SQL setup it would lead me in the direction of being able to make the model or if there was a way of building the relational model then it would be a simple step from there, unless someone has the original answer - or all of them haha, hope you can help!
Thanks,
Jacob
If you are struggling with creating an EER diagram, my guess is that you may not have captured detailed enough requirements for the application. A clear understanding of the functionality the application should provide should lay the groundwork for what you need to model in the database.
Ask yourself these questions.
Have I created user profiles for each type of user the application will be used by?
Have I outlined every action these users will be performing on the application and the details of the actions?
These are just two of many questions that you have hopefully fully addressed. If you have addressed these topics and everything else fully, perhaps you just need a different approach in organizing your requirements.
Break it up into segments of data. For example, you'll need to create a system of tables that manages inventory. Which will need to then be linked up to a system of tables that manages sales and service records. Which will need to be linked to a system of tables that manages customers data. The sales/service and inventory control will need to be linked up to a system of tables that governs employees and their roles and ability to do things (security, privileges, etc). I can go on and on speaking theoretically about this, but this should hopefully be enough to get you started.
Good luck.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Do you know a good source to learn how to design SQL solutions?
Beyond the basic language syntax, I'm looking for something to help me understand:
What tables to build and how to link them
How to design for different scales (small client APP to a huge distributed website)
How to write effective / efficient / elegant SQL queries
I started with this book: Relational Database Design Clearly Explained (The Morgan Kaufmann Series in Data Management Systems) (Paperback) by Jan L. Harrington and found it very clear and helpful
and as you get up to speed this one was good too Database Systems: A Practical Approach to Design, Implementation and Management (International Computer Science Series) (Paperback)
I think SQL and database design are different (but complementary) skills.
I started out with this article
http://en.tekstenuitleg.net/articles/software/database-design-tutorial/intro.html
It's pretty concise compared to reading an entire book and it explains the basics of database design (normalization, types of relationships) very well.
Experience counts for a lot, but in terms of table design you can learn a lot from how ORMs like Hibernate and Grails operate to see why they do things. In addition:
Keep different types of data separate - don't store addresses in your order table, link to an address in a separate addresses table, for example.
I personally like having an integer or long surrogate key on each table (that holds data, not those that link different tables together, e,g., m:n relationships) that is the primary key.
I also like having a created and modified timestamp column.
Ensure that every column that you do "where column = val" in any query has an index. Maybe not the most perfect index in the world for the data type, but at least an index.
Set up your foreign keys. Also set up ON DELETE and ON MODIFY rules where relevant, to either cascade or set null, depending on your object structure (so you only need to delete once at the 'head' of your object tree, and all that object's sub-objects get removed automatically).
If you want to modularise your code, you might want to modularise your DB schema - e.g., this is the "customers" area, this is the "orders" area, and this is the "products" area, and use join/link tables between them, even if they're 1:n relations, and maybe duplicate the important information (i.e., duplicate the product name, code, price into your order_details table). Read up on normalisation.
Someone else will recommend exactly the opposite for some or all of the above :p - never one true way to do some things eh!
I really liked this article..
http://www.codeproject.com/Articles/359654/important-database-designing-rules-which-I-fo
Head First SQL is a great introduction.
These are questions which, in my opionion, requires different knowledge from different domains.
You just can't know in advance "which" tables to build, you have to know the problem you have to solve and design the schema accordingly;
This is a mix of database design decision and your database vendor custom capabilities (ie. you should check the documentation of your (r)dbms and eventually learn some "tips & tricks" for scaling), also the configuration of your dbms is crucial for scaling (replication, data partitioning and so on);
again, almost every rdbms comes with a particular "dialect" of the SQL language, so if you want efficient queries you have to learn that particular dialect --btw. much probably write elegant query which are also efficient is a big deal: elegance and efficiency are frequently conflicting goals--
That said, maybe you want to read some books, personally I've used this book in my datbase university course (and found a decent one, but I've not read other books in this field, so my advice is to check out for some good books in database design).
It's been a while since I read it (so, I'm not sure how much of it is still relevant), but my recollection is that Joe Celko's SQL for Smarties book provides a lot of info on writing elegant, effective, and efficient queries.