ER/Relational Table to Database

问题

So I have the following SQL commands for the description below. I am not sure I have the constraints right especially for the foreign keys, and when to use not null and when not too. Can someone verify if the commands are correct, based on the database description?

1. Car Dealerships have a unique business id number, dealership name, city, state, and a unique website URL. The business id is a number in the range from 1000-9999.
2. Salespersons have a first name, last name, age, gender, and a unique employee id number. The employee number is in the range 100-999.
3. Customers have a first name, last name, city, state, gender, age, and a unique taxpayer id number. The taxpayer id number is 9 digits.
4. Cars have a make, model, year, suggested price, and a unique vehicle id number. A car can have (possibly multiple) colors that should be modeled as an attribute. Note: the make of a car is the manufacturer (e.g., Ford, Honda, BMW) and the model is the name of the model (e.g.Civic, Accord, CRX).
5. Salespersons work for dealerships. In order to be in the database, a salesperson must work for a dealership. However, a dealership may exist in the database without any salespersons. Dealerships have many salespersons who work for them, and a salesperson may work for many different dealerships. The database should record the start date when a salesperson began working for a dealership.
6. Dealerships own cars. A dealership may own many cars, or they may be completely out of inventory and own zero cars. A car can only be owned by one dealership and must be owned by a dealership in order to be in the database. The database should record the date that the dealership acquired the car and the price that the dealership paid for the car.
7. Salespersons sell cars to customers. Even if a salesperson has not sold any cars to customers they should still be stored in the database. However, the database should only store information about customers who have purchased a car from a salesperson. Information about cars owned by dealerships should be stored in the database regardless of whether they have been sold or not. A salesperson may sell a particular car to only one customer. Similarly, a customer may purchase a particular car from only one salesperson. However, a customer may purchase more than one car from the same salesperson. When a salesperson sells a car to a customer, the sales price and date should be recorded in the database.

create table Car_dealership(
Business_id int check ( 1000 >= business_id <= 9999),
b_name varchar(30) not null,
b_city varchar(20) not null,
b_state char(2) not null,
web_url varchar(100) not null,
primary key (Business_id)
);

create table salesperson (
employee_id int check ( 100 >= employee_id <= 999),
first_name varchar (30) not null,
last_name varchar (30),
age int check (0 < age < 130) , 
gender char(1),
/* assumed gender is either Male (M) or Female (F) */
primary key (employee_id)
);

create table customers (
taxpayer_id decimal(9,0),
first_name varchar (30) not null,
last_name varchar (30),
age int check (0 < age < 130), 
gender char(1),
/* assumed gender is either Male (M) or Female (F) */
city varchar (20),
state char(2),
primary key (taypayer_id),
);

create table cars (
vehicle_id int,
make varchar(30),
model varchar(30),
make_year year,
suggested_price int, 
business_id int, 
date_acquired date,
price_paid int,
primary key (vehicle_id),
foreign key(business_id) references Car_Dealerships (business_id)
);

create table car_colors (
vehicle_id int,
colors varchar (30),
primary key (vehicle_id),
foreign key(vehicle_id) references cars (vehicle_id)
);

create table works_for (
business_id int,
employee_id int,
start_date date not null,
primary key (business_id, employee_id),
foreign key(business_id) references Car_Dealerships (business_id),
foreign key(employee_id) references salesperson (employee_id) 
);

create table sells (
vehicle_id int,
taxpayer_id int,
employee_id int,  
sale_price int, 
date_sold date,
primary key (vehicle_id) ,
foreign key(vehicle_id) references cars (vehicle_id),
foreign key(taxpayer_id) references customers (taxpayer_id),
foreign key(employee_id) references salesperson (employee_id)
);

回答1:

Problem • "Education"

Answering your question is fairly easy. I took your text and progressed it to the finished product rather quickly. There are technologies and methods that we in the real world have had for 50 years:

1. Theory
   the Relational Model

And for 35 years:

2. Relational Data Modelling
   IDEF1X, the Standard for Relational Data Modelling,
   and note that it is graphical, not textual.

3. SQL Platform
   a real platform, the data sub-language for the Relational Model.
   Beware, there are many pretend-sql providers (not SQL because they do not comply with the SQL Standard; no ACID Transactions; etc)
   that provide suites (not platforms, because they have no Server Architecture; no decent concurrency; etc).

4. Model, not Text
   See [2] above.

   • Note that text and single-character symbols engage the left hemisphere (4-6% of brain power), and that diagrams engage the right hemisphere (94-96% of brain power).

_{(There are, of course, more Standards that are required to be utilised when building a complete application, which must be mentioned, but that is not relevant to your question, and thus not enumerated here.)}

So in the real world, at least in the high end of the market, which is my domain, life is easy; straight-forward, we can model and build databases and apps correctly and quickly, and we can change them easily as per expansion requests.

But that is not what is being taught at universities, at tertiary level. What is being taught, as evidenced in your question, and the thousands of similar question on StackOverflow, is defunct and anti-relational, heavily promoted (eg. your textbooks and all the professors that use them), falsely labelled as "relational". Essentially pre-Relational technology, using pre-Relational methods.

1. Theory
   1960's Record Filing Systems, instead of the Relational Model, but labelled "relational". Or worse, actual Relational Algebra, and then asking you to work out queries from that, instead of from the data model. Primitive in the extreme.

2. Non-Relational Data Modelling
   ERD (which was great up to 1984, but defunct since the advent of Relational Modelling using IDEF1X), and its dozens of variations

   • Separate to the fact that ERD can not, and does not, handle the central requirements of the Relational Model, such as Relational Keys, which are composite natural Keys, and separate to the fact that it does not prepare the model for Normalisation, it is grossly inadequate in detail; in specification.

   • Therefore it is not reasonably possible to leap from an ERD to SQL DDL, or even to come up with an "improved" ERD.

   • Whereas, the IDEF1X Standard, which was developed and perfected after the RM, and is specifically for the RM, does allow the model to define Relational components, such as the Relational Key, and does allow the model to progress from modelling simple elements, to complex and fully detailed specifications.

   • In fact, most Relational Modelling tools squirt SQL into the server with one click of a button, and the database ready for DML coding.

3. Text, not Model
   Fiddling with text, both at the "theoretical" level, and at the modelling level (which was great when we did not have drawing tools or modelling tools, but defunct ever since). That includes working at the SQL code level to expose issues and to deal with them, instead of doing that in, and from, the data model.

The Crippling Obstacle

Therefore it is quite straight-forward to process the given info, and to create the required result. Using tools we have had since 1984. But it is very difficult, if not impossible, to do so using ancient methods and primitive tools that are defunct, obsolete, since 1984. While still maintaining a teaching question-and-answer context.

• Eg. if you ask me to transport you from Los Angeles to San Francisco, I can do it in under 8 hours (I have done it a few times). But if you ask me to do that your (professor's) way, using a horse and cart, and stopping every time the horse gets tired or the cart needs repair, it will take somewhat longer.

Therefore, as evidenced in your question and thousands of others, you are not being educated in the required science, you are being indoctrinated into false "science". Feel free to print this page off, and give it to your "professor".

The question, the exercise, is actually a good one, well thought out. But again, the correct answer (that satisfies all the requirements detailed) is impossible to work out without using a Relational Modelling method (it cannot be worked out using legless ERD as the modelling method, which is what you have been "taught" to use). The exercise is a modelling one, definitely not a translation (ERD to SQL) one.

My Scope

Therefore, answering the question, using the normal tools we have had since 1984, is easy, but doing so from ERD, which does not have the necessary detail, is impossible. Like leaping from the horse cart in Los Angeles into a seat on a train that just arrived at San Francisco.

Relational Data Model

I will give you the result, an IDEF1X data model that satisfies the requirement. One of the great powers of a Standard is that it defines all details required (ie. all rules and constraints), not only the detail that the modeller understands, and it can be rendered at any level that is required (Table; Table-Key; Table-Key-Attribute; ... Datatype; etc). I am giving you the Table-Attribute level, you can work out the SQL DDL that is required.

• Yes, I looked at the ERD (I assume you were given that), which is manifestly inadequate, and impossible to model the required detail in. Even though that (the exercise of modelling) is the place where you are supposed to work out the solution.

• Yes, I looked at your Record Map, which is an excellent effort to overcome precisely the problem I have described. Your logical ability, and intuitive capability in coming up with that, needs to be acknowledged.

Note • Notation

• All my data models are rendered in IDEF1X, the Standard for modelling Relational databases since 1993.

• My IDEF1X Introduction is essential reading for beginners.

Note • Content

1. Keys
   Your "professor" has given the Keys for each hierarch as a defined thing, that is unique. This is streets ahead of the 1960's Record Filing Systems that are commonly taught, which is characterised by a Record ID field. By the grace of God, you are not being taught that primitive stuff.

   • But the names given to those Keys are not very good. So I have kept what they contain (not an id, which has RFS connotations and limitations, but a number, with the range definition) and given them better, more meaningful names.

2. Missing Keys
   No idea as to whether you are required to identify missing elements (usually you are). These are in order to (a) either prevent duplicate rows, or (b) ensure sanity. I have supplied the Alternate Keys in Dealer; Person; and Customer.

3. DealerCar

   A car can only be owned by one dealership and must be owned by a dealership in order to be in the database.

   • Therefore Car is not Independent (even though is has been described as such, and an Unique Key is given). (See FAIL model below for a comparison.)
   • Therefore Car is Dependent, it exists only in the context of being owned by a Dealer: DealerCar. Which means (like SalesPerson), the Car PK is the Dealer PK plus a differentiator.
   • That differentiator is of course the given Car Key (VehicleNo), the Primary Key is (BusinessNo, VehicleNo). The relevance of that is defined later.
   • Separately, to maintain Car as an unique entity, the Car Key (VehicleNo) is an Alternate Key in DealerCar.
   • Maintaining the Car Key as an AK through to CustomerCar ensures that the Car remains unique: it can be sold to only 1 Customer; it can be sold by only 1 SalesPerson

4. SalesPerson
   Because a Person can be employed by more than one Dealer, the Fact of a SalesPerson, and therefore the Key, is not that as given (EmployeeNo), but (BusinessNo, EmployeeNo). Modelled.

5. CustomerCar

   a customer may purchase a particular car from only one salesperson.

   • Stated better, a DealerCar can be sold by only 1 SalesPerson
     And a DealerCar can be sold to only 1 Customer
     Implemented by the Fact that VehicleNo is unique in CustomerCar.

   • But there is more. Stated more precisely, a DealerCar (which is owned by only 1 Dealer) can be sold by only a SalesPerson who is employed by that Dealer. (Otherwise a SalesPerson can sell a DealerCar that belongs to a Dealer that he does not work for.) Therefore, due to the implementation of composite Relational Keys:

     • The DealerCar PK is 1::1 in CustomerCar
     • The SalesPerson PK is 1::n in CustomerCar, wherein (BusinessNo) must be the same as DealerCar. (More below.)
     • And although a Customer purchases a Car from 1 SalesPerson, he is actually purchasing a DealerCar, from a Dealer::SalesPerson (BusinessNo, EmployeeNo).

6. CarColour

   A car can have (possibly multiple) colors that should be modeled as an attribute.

   That breaks 1NF: .
   Each attribute must be Atomic wrt the platform
   .
   Sorry, no way Jose, I will not model an error. Colour is a repeating column, it belongs in a subordinate table. Modelled.

7. Age
   Storing values that change (relative values) is a very silly thing to do: every year or every quarter, the table will have to be updated to reflect the changing Age. Relative values are not Facts, and thus should not be stored. The unchanging Fact is, the Person's BirthDate. From which the value Age can be easily derived.

8. Null
   Good concern. Since the data model is fully Normalised, there are no NULLs, all the columns are NOT NULL. A Nullable column is a clear indicator that Normalisation is incomplete.

9. Business Rule/Constraint
   A database is a self-contained and self-defining recovery unit. Therefore, it is correct to place all business rules and constraints, all Transactions, in the database container. But of course, the rules are of different types, and they will be deployed in different ways: RULES; CHECK and other CONSTRAINTS; Indices (PRIMARY KEY; UNIQUE); Transactions (CREATE PROC); etc.

   • Thus one has to read the data model precisely, and translate each item to the appropriate DDL command.

   • Further, all Constraints (eg. Transactions) cannot be shown in the Data Model (unless extended). They have to be documented in Process Models or Objects Transactions are the Database API, in OO terms, they are Methods.

   • In any case, the remainder (the rules in the requirement that have not been explicitly explained above) are minor, easily read from the data model. It would be TLDR if I give them here (and this is already long!). Therefore I have given that detail; how it is implemented; etc, in a PDF. Enjoy.

The SQL DDL

Your task is you choose the mission. You have already provided the first cut for the SQL DDL that is required. Great work, jumping the modelling gap. Hopefully, you can read the IDEF1X data model, which has more detail (read my IDEF1X Introduction, and progress the SQL DDL to that which is defined in the data model.

Relational Integrity (via Relational Key)

One thing that the exercise exposes, and thus teaches, that is very important, is this. Note that your "professor" may or may not know or understand this Relational concept:

• If he does know this, that is great, he has chosen an exercise that consciously teaches it.

  • But he has not given you the tools or the education that is required to complete the exercise.

• If he does not know this, then the answer (whatever data model type & SQL) that he considers to be correct and perfect, is a total failure as a Relational solution.

The Relational Data Model I have given above is of course correct and complete. Precisely because it employs Relational Keys, which are (a) natural, and (b) composite. When such Primary Keys are migrated as Foreign Keys into subordinate tables, Relational Integrity, which is logical (as distinct from Referential Integrity, which is physical, and a mere feature of SQL), is implemented in the subordinate table.

• Eg. A SalesPerson can sell only DealerCars that are owned by a Dealer who the SalesPerson is employed by.

• Likewise the Customer can buy only DealerCars from a SalesPerson, that are owned by a Dealer who has employed the SalesPerson.

Data Model • Fails Relational

Here is a data model erected by a person who does not understand Relational Keys, or Relational Integrity, who implements just the Keys that are given. I will include the other errors so that a comparison with the correct model can be obtained readily.

1. Relational Key

   At least your "professor" has given unique Keys in the data, which is good for the hierarchs.
   In the usual indoctrination, wherein 1960's RFS is taught as "relational", the "keys" are physical Record IDs.
   The point being,

   • all RFS solutions (no Relational features whatsoever),
   • as well as any half-baked Relational solution (ie. Relational concepts understood and attempted, but not Relational Keys and the Relational Integrity that they provide),

   have this gross error.

   • Here, I have used the given keys, but not modelled them as Relational Keys, Relational Integrity is lost (yes, yes, we still have Referential Integrity, to the level that is modelled). The Keys are treated as given, only, as single columns units (logically, that means fragments of the actual logical Key that is required for the purpose, the Fact).

   • The model is correct for RFS, and limited to that primitive level, but it is a failure as a Relational data model.

   • A SalesPerson can sell a DealerCar that belongs to any Dealer, ie. a Car that is not constrained to a Dealer where he is employed as a SalesPerson. Oopsy.

   • Likewise, a Customer can purchase a Car from one Dealer & SalesPerson, where the DealerCar that does not belong to that Dealer; SalesPerson. Oopsy doopsy.

2. Car
   I have modelled Car as Independent, which is a slavish modeling of the stated requirement re Car. But it fails to model this requirement:

   A car can only be owned by one dealership and must be owned by a dealership in order to be in the database.
   When modelled correctly, Car is a thing that is owned by a Dealer, and all the Car attributes, which are 1::1 with the Car PK (VehicleNo), move into DealerCar.

3. Colour
   I have shown the Colour as per the requirement, a CSV list, which is incorrect.

Enjoy.

---

来源：https://stackoverflow.com/questions/59132125/er-relational-table-to-database