预定酒店的类图与E-R模型

本文主要对某年代澳大利亚某线上酒店预订网站进行数据库建模，相关的业务文档：
https://download.csdn.net/download/qq_33559972/10366961
上一步的用例建模工作参考我上一篇博客，上面开头把澳大利亚写成了意大利，特此更正：
https://blog.csdn.net/qq_33559972/article/details/80044209

类图模型

Task 2 制图要求：
1.识别系统中的类及其属性，给出各个类之间的联系
2.识别类中的entity和mediator，并对应地将类的命名冠以字母E/M
E 一般与数据库构建有关，M 一般与store/session模式有关

设计说明：

• 这个图有点复杂，所以我做了一些标注方便阅读：底部是数据库的foundation，是一些相对静态的数据和资源；右侧与支付相关，跟订酒店的流程没多大关系，但确实是从系统中识别出来的类而不应抛弃；中上部分可以按照我的虚线指引着看，它符合订酒店的用例流程和用户的操作顺序。
• 黄色的类均为实体，需要数据库持久化保存；粉色的类则均为中间实体，它们可能为不同的页面共享并以某种形式临时保存，加深的两个是用户发起的两个查询请求；还有一些类没有底色，它们都不符合以上两种，例如card detail甚至不需要临时保存，room desc没有对应现实世界里某种看得见摸得着的东西，它在数据库里也许只是room表的一部分。
• room desc中的desc是description的缩写。list price是指折扣之前的价格。type例如豪华房和标间，按照文档还可能包含newspaper等服务描述，但选择type的过程没有给出因此这里简略用一个type。
• traveler是指网站的游客，因为这个网站并没有登陆注册的机制，所有用户信息都体现在订单中。他与hotel request的logged关系源于检测酒店热度的需求，热度可以以搜索次数来衡量，但也可以有其它方式，所以这个关系其实不一定。
• 两次搜索request将会分别返回hotel和room列表，用户做出选择之后写到summary和order item中，并最终包含到reservation中，因此设计上reservation与hotel和room的没有直接联系。并且，系统允许用户在选择的流程中循环，不断提出新的查询，更改自己的选择。
• 一些数量关系在仔细研读文档之后确定：一次下单操作是对一家酒店而言的，可以同时订多间房；一次下单操作就要求给出一份住客信息（才能加入shopping basket），因此reservation与customer info是一一对应；能否对不同的reservation使用不同的credit card支付这一点不明确，但参照Screenshot 9给出的提示语“You may choose to pay with same card for different products”，我姑且认为它是可选的支持多卡的，故图中credit card一端给出1..n。

E-R模型

Task 3 制图要求：
1.只转化实体类和他们之间的关系
2.用自动工具将图转化成关系数据库模式

MySQL Workbench下载链接：https://dev.mysql.com/downloads/workbench/
使用教程：https://blog.csdn.net/xujiayin/article/details/51689749
设计说明：

• room表的available date应该是一个类似于数组的结构，但在数据库中就要单独提出来作一个表了。
• location中增加了一个type字段用于表示它是region还是city还是town，又增加了一个is_capital字段表示当它是一个城市时是否是首都。
• credit card在task2中被要求设计为一个实体，但其实不作为一个实体写在数据库里也可以的，“支持很多种卡的支付”只需要反映在前端的设计中，所以这里就不画了。

导出 Mysql 物理数据库的脚本：

-- MySQL Script generated by MySQL Workbench
-- Sun Apr 29 23:52:55 2018
-- Model: New Model    Version: 1.0
-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`room_desc`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`room_desc` (
  `type` VARCHAR(50) NOT NULL,
  `list_price` FLOAT NOT NULL,
  PRIMARY KEY (`type`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`availiable_date`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`availiable_date` (
  `date` SMALLINT(30) NOT NULL,
  `isAvailiable` TINYINT NULL DEFAULT 1,
  PRIMARY KEY (`date`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`location`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`location` (
  `code` INT NOT NULL,
  `name` VARCHAR(10) NULL,
  `hot` SMALLINT(5) NULL,
  `type` SMALLINT(3) NULL,
  `isCapital` TINYINT NULL DEFAULT 0,
  PRIMARY KEY (`code`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`hotel`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`hotel` (
  `name` VARCHAR(50) NOT NULL,
  `intro` TEXT(100) NULL,
  `star_index` SMALLINT(5) NULL,
  `hot_index` SMALLINT(5) NULL,
  `address` TEXT(80) NULL,
  `location_code` INT NOT NULL,
  PRIMARY KEY (`name`, `location_code`),
  INDEX `fk_hotel_location1_idx` (`location_code` ASC),
  CONSTRAINT `fk_hotel_location1`
    FOREIGN KEY (`location_code`)
    REFERENCES `mydb`.`location` (`code`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`room`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`room` (
  `number` MEDIUMINT NOT NULL,
  `room_desc_type` VARCHAR(50) NOT NULL,
  `availiable_date_date` SMALLINT(30) NOT NULL,
  `hotel_name` VARCHAR(50) NOT NULL,
  PRIMARY KEY (`number`, `room_desc_type`, `availiable_date_date`, `hotel_name`),
  INDEX `fk_room_room_desc_idx` (`room_desc_type` ASC),
  INDEX `fk_room_availiable_date1_idx` (`availiable_date_date` ASC),
  INDEX `fk_room_hotel1_idx` (`hotel_name` ASC),
  CONSTRAINT `fk_room_room_desc`
    FOREIGN KEY (`room_desc_type`)
    REFERENCES `mydb`.`room_desc` (`type`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_room_availiable_date1`
    FOREIGN KEY (`availiable_date_date`)
    REFERENCES `mydb`.`availiable_date` (`date`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_room_hotel1`
    FOREIGN KEY (`hotel_name`)
    REFERENCES `mydb`.`hotel` (`name`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`reservation`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`reservation` (
  `id` INT NOT NULL,
  `total` FLOAT NULL,
  `check_in` DATE NULL,
  `check_out` DATE NULL,
  `customer_name` VARCHAR(45) NULL,
  `customer_email` VARCHAR(45) NULL,
  `customer_sex` TINYINT NULL,
  `customer_is_smoke` TINYINT NULL,
  `customer_special_requirement` VARCHAR(45) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`oder_item`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`oder_item` (
  `number_of_adults` INT NULL,
  `number_of_children` INT NULL,
  `age_of_children` INT NULL,
  `room_number` MEDIUMINT NOT NULL,
  `room_room_desc_type` VARCHAR(50) NOT NULL,
  `room_availiable_date_date` SMALLINT(30) NOT NULL,
  `room_hotel_name` VARCHAR(50) NOT NULL,
  `reservation_id` INT NOT NULL,
  PRIMARY KEY (`room_number`, `room_room_desc_type`, `room_availiable_date_date`, `room_hotel_name`, `reservation_id`),
  INDEX `fk_oder_item_room1_idx` (`room_number` ASC, `room_room_desc_type` ASC, `room_availiable_date_date` ASC, `room_hotel_name` ASC),
  INDEX `fk_oder_item_reservation1_idx` (`reservation_id` ASC),
  CONSTRAINT `fk_oder_item_room1`
    FOREIGN KEY (`room_number` , `room_room_desc_type` , `room_availiable_date_date` , `room_hotel_name`)
    REFERENCES `mydb`.`room` (`number` , `room_desc_type` , `availiable_date_date` , `hotel_name`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_oder_item_reservation1`
    FOREIGN KEY (`reservation_id`)
    REFERENCES `mydb`.`reservation` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

数据库逻辑模型与领域模型的异同：
一、相同：

• 都描述了实体及其属性，和他们之间的关系。

二、不同：

• 领域模型是面向用例的设计，所以它还会考虑中间实体等等；而E-R模型是面向编码的设计，只考虑实体。
• E-R模型需要考虑属性的取值范围以确定字段。它会引导我们进一步考虑那些属性，甚至建出新的表以满足需求。
• E-R模型对关系的表述更加抽象化，抽象为主键外键的表示。