database - 在开发新系统时-是否应始终与利益相关者讨论数据库模式？

Question

我比我将要描述的项目涉及的人员高出几层/几层。
一般的需求是基于web的问题管理系统。这个系统是一个大得多的项目的一小部分。
首席项目经理有一名技术项目经理，负责处理项目的这一部分。主管PM问我，帮助信息不在请求帮助的上下文中是否正常。项目经理负责人提供了关于站点的反馈，并希望有模态对话框等错误信息，希望我看看。我在看系统，我在想…
一个新的应用程序是在冷聚变中开发的！？！是吗？
应用程序的数据验证非常差
应用程序数据验证页从数据输入窗体中导航
应用程序帮助页从窗体中导航
开发人员和项目经理没有讨论数据库模式
DB架构未被讨论，因为它不存在。
有一个菜单页，也就是说，一旦你进入一个页面，你必须回到主菜单，然后进入下一个你想要的页面
项目经理不知道数据库管理系统是什么…
有一个技术项目经理，她不知道什么是数据库管理系统…
首席项目经理想解雇技术项目经理很长一段时间了，但技术项目经理是受保护的…
领先的PM建议，在几个专有项目（其中有几个是开源的bugtracker，BugZILA等）存在的确切功能，但技术PM和DEV不听。
我有两个问题？
是吗？
解雇开发人员？
解雇技术经理和保护她的人？
解雇首席首相？
为他们下载并配置bugtracker/bugzilla，然后全部启动？
为他们下载并配置bugtracker/bugzilla，然后去喝杯啤酒忘记我的悲伤？
在项目的早期，讨论和严格考虑db模式不是很好吗？
编辑：
我曾经和各种各样的客户一起工作，他们拥有不同水平的技术知识（和智力）。我总是和干系人讨论数据库模式。如果他们不知道什么是模式，我会教他们。如果他们没有背景知识，我仍然会和他们讨论这个模式——即使他们没有意识到我们在讨论这个模式。在我直接参与的大多数项目中，数据是系统中最重要的部分。彻底地散列模式/域模型对于很好地理解系统以及可以做什么和报告什么是至关重要的。我很尊重海报上的意见。有趣的是，我的方法不是通常的方法。
顺便说一下，可悲的是，该项目使用纳税人的资金，而信息技术部分是与一所著名大学的合作…开发和技术项目经理是长期的员工，他们不是没有经验。当我知道聪明又勤奋的人没有工作，像这样的人有工作的时候，我觉得特别难过。
当我年轻的时候，我会向上报告这种无能，并期望采取适当的行动。现在我已经上了链，我发现自己不想微观管理别人的责任。
我的决心是喝两杯啤酒然后重新开始我的职责…

Answer 1

数据应该与利益相关者讨论，绝对是的。数据库模式不应该与涉众讨论，除非在特殊情况下，涉众都“精通数据库”。
那么，如何在不讨论数据库模式的情况下讨论数据呢？这是我发现的实体关系（ER）图和一般ER模型的主要用途。许多数据库设计者倾向于将er视为关系数据建模（rdm）的一个简化版本。以我的经验，如果你不认为它是淡化了的rdm，那么它可以被更有效地使用。
急诊室和急诊室有什么区别？在RDM中，多对多关系需要中间的接线盒。此接线盒包含将接线盒链接到多对多关系中的参与者的外键。
在ER中，严格应用时，接线盒在多对多关系中是不必要的。你只需要把这段关系表示成一条线，并在这条线的两端表示“多”的可能性。事实上，er图根本不需要外键。通过外键链接的概念可以不在大多数用户的讨论范围内。
数据规范化与er图完全无关。一个构建良好的er图几乎没有有害的冗余，但这很大程度上是偶然的，不是精心计划的结果。
面向干系人的er图中的“实体”和“关系”应仅包括主题专家理解的实体，而不包括在逻辑数据库设计过程中添加的实体或关系。
要保存在数据库中并按需提供的值可以连接到属性，而属性又可以连接到实体或实体之间的关系。此外，属性可以绑定到域，域是每个属性可以接受的一组可能值。存储在数据库中的一些值，如外键，应该在与大多数涉众的讨论中忽略掉。
理解数据的利益相关者通常对这些概念有直观的理解，尽管术语“实体”、“关系”、“属性”和“领域”对他们来说可能并不熟悉。不了解主题数据的利益相关者需要特殊处理。
er模型和图表的美妙之处在于，它们不仅可以用于讨论数据库中的数据，还可以用于讨论用户可以看到的表单中的数据。如果你有任何利益相关者不了解表格和填写表格，我的建议是，如果仍然有可能的话，尽量让他们远离电脑。
通过一个相当机械的过程，可以将构建良好的er图转换为构建良好的关系模式。一个更具创造性的设计过程可能会产生一个逻辑上等价的“更好”的模式。一些技术涉众需要理解关系模式，而不仅仅是er图。不要把关系模式展示给不需要知道它的人。