健身房系统需求

1、下面大体介绍此程序。需强调的是，这里有很多不完整或模糊的地方。设计者需要找出潜在的热点，分析并提出符合整 个发展项目的设计方案。这阶段的分析成果应该在程序说明文件中适当的点出。健身房的说明：在健身房有机会获得两种不同类型的人：定期用户和不定期的用户。定期用户订健身房卡，同时 不定期的用户每次进入付固定的钱，并没有任何订卡。每个去健身房的人要储存以下信息：姓，名，id号码，地址，电话号码，出生日期，出生地点和 任何客户关注的。定期用户有一个独特的卡确定一个卡号。定期用户分为两类：学生和工人。学生对所有类型的订阅有20 %的折扣费，而工人的附属机构 的健身房有一个折扣取决于他们自己。每个定期用户有

2、一个特定类型的订阅。每种类型的用户有个确定代码，只有权参加选择的课程或 厅室或两者皆可。此外，每个订阅有一个认购期（其中一年，六个月，三个月，一个月不等）， 价钱，一个场所用来存储任何相关的订阅和订阅给予的奖励（免费太阳能灯，优惠券在体育用品 商店等）.当一个人办了订阅健身房后，需要储存开始日期和终止日期。这一信息必须符合有关的选择订阅 的类型。只可在这段日期内进入健身房。用户可以订阅健身房即使没有医疗证明。有一个月时间 来补办医疗证明。一个月后，如果仍然没有医疗证，不再有资格进健身房。当一个人续订购，相关的资料将从以前的数据库删除。所以对于用户订阅历史不感兴趣。在健身房有一定的课程。这些课程

3、都有唯一代码，类别（健美操，步骤，踢拳击等），哪天上 课，时间（例如：上午9-10点），1名体能教练，课程水平等级（1至5, 1显示的课程为初学 者，5为高级课程）。请注意，每个课程有固定的地方上课。这样就不可以同时进行两种不同的 课程。任何体能教练不能上超过三个小时的课程。在星期六下午（13时以后）没有课程。健身 时间是：（上午9点-10点）每天，星期日除外，健身房关闭至于身体练习，还有一套预先确定的卡分配给进入重量房间的用户。这些卡的特点是代码卡，确 定了困难程度（类似课程）的名字，体能教练创造了卡，看卡是适合男性或女性还是两者皆可， 卡的种类（电路有氧加强，色调等），估计平均时间（一小时

4、，两小时等。）做一个卡要多久 （一个星期，一个月，两个星期，等等。）一星期应该做多少次。对于每一个信用卡有特定数 目的运动。每个运动的特点是，做运动的机器的名称代表运动本身。它也想追踪每个重复设置的 数量和卡上规定的运动的实现数量。当一个人申请进入健身房的重量房间，必须有一个卡片。应该指出的是，该卡对于完成卡片的人 得性别有限制。我们希望保存获得卡的日期信息，教练允许改变卡的日期，这可能和原来创造的 卡不同。当到了假设的变化形式日期，体能教练召集用户，作改变或确认目前的分配。您只可以 变更到比当前高一级或低一级或同级的水平。可证实是目前使用的。应当被存在数据库的历史卡 中，直至该人注册到健身房

5、。要管理每个进入健身房的数据库。对于每一个进入的人，保存日期，进入时间和出去时间。凡 进入参加一个或多个小时课程的要记录他们参加了什么课程。不定期的用户来五次后有资格获得 一次免费的进入。对于定期的用户和订阅类型挂钩，一个人拥有。在有效期届满之日起的情况下 要删除订阅进入的有关条目。下面介绍一些例子，一些（但不是全部的约束），必须验证：一个人注册为临时用户可以随时进入，但不能在同一天同一个小时进入两次。如果在一天的不 同时间进入两次需付两倍的钱2一个只订阅了课程的人，不可以在没有课程的时候进入3一个只有权访问重量房间的人，不能参加课程。php应用开发上面的数据和操作应该可以通过网络看见。由于数

6、据库包含机密信息，这些信息不能被访问所有， 都要求考虑3个类别的用户：1。一般用户。它可能只看到这些资料被认为是公共领域（在此用户不应当允许变更和注销）。2。健身房员工。他们可以存取所有的数据库内的资料（该用户允许进行任何行动的修正和取 消）。教练就是员工。3。订阅用户。可以执行编辑涉及个人档案的业务应该交：-er图，及重改的概念表格-er图变形约束条件，在er图上不可以直接看出，和在sql上的相关实验。对于那些无法实施在PostgreSQL 的约束，替代通过。造成关系模型，从设计阶段。 SQL代码任何其他资料被认为重要的是了解设计和实施作出的选择（包括不同类别的人可以做的事情）Er图需用到以

7、下图像I实体，联系，属性，key属性，概括层次，联系例子Schema ERNOME O43变形DATACOG?iOME N01IE TELCELL, OIXFERMIERI DOMICILIARESOnnNISTR-JLZIONEORA DOSEINTERMIERESERIZIOQRAFOEArQ (1：1)TARMACOZONACOD NOME ODISPONIBSER1IZIO DOMICILI.YREDISP丫侦如1 ASchema ER RistrutturatoOSPEDALEPAZIENTENOIENOME O-T- COGXOME DLT1EL OSIRIZIOOSPEDALIE

8、ROREE.4RTO T ecC.U1ERA LETT。HomeMEZZI关系模式Traduzione nel modello relazionalePaZIENTE(NomerCoqnome,TeL Descriz； EtaF)INOTE(NomePAZIENTEXognomePAZIENTEJ)OSPEDALE(NomeO)ZONA(CodZome)FARMACOflNomeF)INFERMIERE(CellIfNome/CognomeJel)DISPONIBILITAK辿inferuiere 回四也也芦)INFDOMIC(3IiNFERMiERE,indi)MEZZI(CellimFWMM 就 zo)PER(BIII 讷 FERMIERENomeOOSPEDALE)SlXCellP 町 ggCodZRZ)SERVIZIOJCodS, /VomWE件 cognomePPAZTE!Ef Dataf Oral, OraF)SERVIZIODOMIC(CodS5ERVIZI. Via, NCiv；