I want to address only the concern that joining to mutiple tables will casue a performance hit. Do not be afraid to normalize because you will have to do joins. Joins are normal and expected in relational datbases and they are designed to handle them well. You will need to set PK/FK relationships (for data integrity, this is important to consider in designing) but in many databases FKs are not automatically indexed. Since they wil be used in the joins, you will definitelty want to start by indexing the FKS. PKs generally get an index on creation as they have to be unique. It is true that datawarehouse design reduces the number of joins, but usually one doesn't get to the point of data warehousing until one has millions of records needed to be accessed in one report. Even then almost all data warehouses start with a transactional database to collect the data in real time and then data is moved to the warehouse on a schedule (nightly or monthly or whatever the business need is). So this is a good start even if you need to design a data warehouse later to improve report performance.

我不得不说你的设计对于一个计算机科学的大一学生来说是令人印象深刻的。

这不是过度设计，这是我处理问题的方式。加入很好，不会有太大的性能损失(这是完全必要的，除非你对数据库进行反规格化，这是不建议的!)对于状态，查看是否可以使用枚举数据类型来优化该表。

不。看起来你设计得很细致。

我认为在你的设计中，国家和公司实际上是同一个实体，城市和部门也是如此。我将去掉国家和城市表(以及Cities_Has_Departments)，并在必要时向公司表添加一个布尔标志IsPublicSector(如果除了简单的Private Sector / PublicSector之外还有其他选择，则添加CompanyType列)。

Also, I think there's an error in your usage of the Departments table. It looks like the Departments table serves as a reference to the various kinds of departments that each customer division can have. If so, it should be called DepartmentTypes. But your clients (who are, I assume, attendees) do not belong to a department TYPE, they belong to an actual department instance in a company. As it stands now, you will know that a given client belongs to an HR department somewhere, but not which one!

换句话说，客户机应该链接到您称为Divisions_Has_Departments的表(但是我将简单地称之为Departments)。如果是这样，那么如果您想在数据库中使用标准引用完整性，就必须将Cities分解为division，就像上面讨论的那样。

I want to address only the concern that joining to mutiple tables will casue a performance hit. Do not be afraid to normalize because you will have to do joins. Joins are normal and expected in relational datbases and they are designed to handle them well. You will need to set PK/FK relationships (for data integrity, this is important to consider in designing) but in many databases FKs are not automatically indexed. Since they wil be used in the joins, you will definitelty want to start by indexing the FKS. PKs generally get an index on creation as they have to be unique. It is true that datawarehouse design reduces the number of joins, but usually one doesn't get to the point of data warehousing until one has millions of records needed to be accessed in one report. Even then almost all data warehouses start with a transactional database to collect the data in real time and then data is moved to the warehouse on a schedule (nightly or monthly or whatever the business need is). So this is a good start even if you need to design a data warehouse later to improve report performance.

我不得不说你的设计对于一个计算机科学的大一学生来说是令人印象深刻的。

你说得对。但是，您可以清理它，并删除一些映射(有*)表。

你能做的就是在部门表中添加CityId和DivisionId。

除此之外，我觉得一切都很好……

我在培训/学校领域工作过，我想我要指出的是，在你所说的“会话”(给定课程的实例)和课程本身之间通常存在M:1的关系。换句话说，你的目录提供了这门课程(“西班牙语101”之类的)，但你可能在一个学期中有两个不同的实例(Tu-Th由Smith教授，wed - friday由Jones教授)。

除此之外，这看起来是个不错的开始。我敢打赌，您会发现客户端域(指向“客户端”的图形)比您所建模的要复杂得多，但在获得一些实际数据来指导您之前，不要过于复杂。