• 2.1 关系数据结构及形式化定义


    思维导图:

     

    2.1.1 关系 

    笔记:

    关系数据库模型是一个简单但强大的方式来表示数据及其之间的关系。下面是这节的关键内容:

    - 关系模型核心概念
     

     

     

     

     

    * 关系数据模型的核心是“关系”,它在逻辑上表现为一个二维表。
      * 此表中,每一行称为一个元组,每一列称为一个属性或域。
      * 数据的逻辑结构只是二维表,这使得关系模型既简单又强大。

    - 域 (Domain)


      * 域定义了可能的值的集合,每个域都有一个与之关联的数据类型。
      * 示例:整数、实数、小于25字节的字符串集合都是有效的域。

    - 笛卡尔积 (Cartesian Product)
      笛卡尔积是定义在一组域上的集合运算。
      如果我们有两个集合,笛卡尔积就是所有可能的元组组合。


    2023/11/23日修改

    我的理解:

    在我看来其实就是两个集合中的元素进行排列组合,所有的可能就是笛卡尔积的结果。

    例如,如果集合 A = {1, 2},集合 B = {a, b},那么他们的笛卡尔积就是 { (1, a), (1, b), (2, a), (2, b) }。这里每个有序对都是从集合 A 中取一个元素和从集合 B 中取一个元素的结果。

    笛卡尔积的个数结论:如果集合 A 有 m 个元素,集合 B 有 n 个元素,那么他们的笛卡尔积将有 m×n 个元素。


    - 元组 (Tuple)
      一个元组是关系中的一行,由多个分量或值组成。
      每个分量代表域中的一个值。
      在示例中,(张清玫,计算机专业,李勇) 是一个元组。


    2023/11/23修改

    我的理解:

    在我看来其实元组其实就是一张二维表的某一行


    - 二维表
       笛卡尔积的结果可以表示为一个二维表,每行表示一个元组,每列表示一个域的值。

    从上述内容中,我们可以理解关系模型的基本构建块:域、元组、关系。这为后续章节介绍关系操作、完整性约束和其他概念打下了基础。

    我的理解:

    关系数据库模型中的概念可以在日常生活中找到相应的类比,以帮助我们更好地理解。以下是对这一节概念的简化和日常类比:

    1. 关系: 想象一张电子表格或Excel表格。这张表格就是一个“关系”。每行代表一个实体(如一个人、一本书等),每列代表实体的某个属性(如姓名、年龄或书的标题)。

    2. 域 (Domain): 域可以看作是一个特定的列可能有的所有值的集合。例如,对于一个“性别”列,域可能是{男,女}。这就像在填写表格时,某列下你只能从特定的选择列表中选择。

     

    3. 笛卡尔积 (Cartesian Product): 想象你有两副扑克牌,你想列出所有可能的两张牌的组合。这样的组合列表就是笛卡尔积的结果。在数据库中,笛卡尔积指的是从多个域中取值形成的所有可能的元组组合。

    4. 元组 (Tuple): 这就像电子表格中的一行。它表示一个完整的记录,例如一个学生或一个订单。

    5. 二维表: 这是整个关系的表示,就像一个完整的Excel表格。在这个表格中,你可以看到所有的记录和它们的属性。

    总结一下:

    - 关系数据库模型其实就是通过二维表来组织和存储数据的一种方式。
    - 这些表中的每一行代表一个记录,每一列代表一个属性。
    - 这些属性的取值范围被称为“域”。
    - 通过组合不同域的取值,我们可以得到许多可能的记录组合,这就是笛卡尔积。

    理解这些基本概念是掌握关系数据库操作、查询和设计的基础。

    3.关系:

     

     


    2023/11/23补充

    1.目:

    在关系数据库的术语中,“目”或“度”(Degree)是指一个关系(即表)中的列数。换句话说,它表示了表中有多少个不同的属性或字段。例如,如果一个表有三列,比如“姓名”、“年龄”和“地址”,那么这个表的度就是3。

    度的概念在数据库设计和理解关系模型时非常重要,因为它直接关系到表的结构和数据的组织方式。在设计数据库表时,确定合适的度有助于优化数据存储、查询效率以及数据完整性。

    • 低度:含有较少列的表(例如,只有两三个字段)。这种表通常更专一,但可能需要与其他表联合使用才能提供完整的信息。
    • 高度:含有较多列的表(例如,十个以上的字段)。这种表能够提供更全面的信息,但可能更复杂,且在某些情况下可能影响性能。

    理解和管理关系表的度是数据库设计和优化的一个重要方面。

    2.候选码:

    候选码是数据库设计中的一个概念,它指的是可以唯一标识数据库表中每一行记录的属性或属性集合。换句话说,候选码是一组属性,这组属性的组合可以保证在表中的每一行都是唯一的。一个表可以有一个或多个候选码。

    候选码的特点包括:

    1. 唯一性:使用候选码的值可以唯一地标识表中的每一行。
    2. 最小性:没有多余的属性,即移除候选码中的任何一个属性都会使得它不再能够唯一标识表中的行。

    举个例子,假设有一个学生信息的数据库表,它包含学生的学号、身份证号和姓名。在这个例子中,学号和身份证号都可以作为候选码,因为它们都可以唯一地标识表中的每个学生。但姓名不是一个好的候选码,因为可能有多个学生共享同一个名字。

    在所有候选码中,可以选择其中一个作为主键(Primary Key)。这个选择基于实际应用的需要,例如数据的唯一性、稳定性和简便性。主键是特殊的候选码,用于数据库中的索引和关系的建立。其他未被选为主键的候选码称为备选键(Alternate Key)。

    3. 主码:

    如果假设研究生不会重名, POSTGRADUATE属性的每个值都唯一地标识了一个元组,因此它可以作为`SAP`关系的主码。


    我的理解:

    主码其实就是为了区分数据而定义的一个概念其实就好比一个学校里每个人的学号其实就是主码用来区分不同的学生,如果以名字做主码就不能一一对应即无法区分,因为有重名的现象

    主码和候选码的区别:

    总的来说,候选码是指一个表中所有可能作为主码的字段集合,而主码是从这些候选码中选出的特定一个,用于数据库中的索引和关系建立。选择哪个候选码作为主码通常取决于实际应用的需求,如数据的唯一性、稳定性和检索效率。其他未被选为主码的候选码则称为备选键(Alternate Key)。

    在我看来主码就是从候选码中选出的,就比如TGA年度最佳游戏奖项有多位提名的游戏,但是最终只有一位能得奖。


    2023/11/23补充

    4.主属性:

    在关系数据库理论中,主属性是指那些至少在一个候选码中出现的属性。简而言之,如果一个属性是某个候选码的一部分,那么它就被称为主属性。

    要理解主属性,首先要明白什么是候选码。候选码是一组属性,这组属性的组合可以唯一地标识表中的每一行记录。如果一个属性在任何一个候选码中出现,那么这个属性就被认为是“关键的”或“重要的”,因此被称为主属性。

    例如,假设有一个数据库表,其中包含以下三个属性:学号、姓名和年龄。如果“学号”是该表的一个候选码,那么“学号”就是一个主属性。如果“学号和姓名”的组合是另一个候选码,那么即使“姓名”单独不是候选码,它也是主属性,因为它是一个候选码的一部分。

    在数据库设计中,区分主属性和非主属性(即不属于任何候选码的属性)是重要的,因为它们对于理解数据的唯一性和完整性有重要意义。主属性通常在数据库设计中被特别关注,因为它们涉及到数据完整性和关系的定义。

    5.非主属性:

    非主属性,也称为非关键属性,是指在关系数据库中不包含在任何候选码中的属性。这些属性与主属性相对,后者至少是一个候选码的一部分,从而有助于唯一地标识表中的记录。

    非主属性的特点包括:

    1. 非唯一性:非主属性本身或其组合通常不能唯一地标识表中的记录。
    2. 不参与候选码:它们不包含在任何候选码中,这意味着它们不是用于确定记录唯一性的关键字段。
    3. 信息描述:非主属性通常用于提供与记录相关的额外信息,但这些信息并不用于标识记录的唯一性。

    例如,考虑一个包含学生信息的数据库表,其中包括“学号”、“姓名”和“住址”。如果“学号”是该表的唯一候选码,那么“学号”是主属性,而“姓名”和“住址”(假设它们不是任何候选码的一部分)则是非主属性。这里,“姓名”和“住址”提供了有关学生的额外信息,但它们本身不用于唯一地标识表中的学生记录。

    在数据库设计中,了解哪些属性是非主属性有助于更好地组织和管理数据,确保数据的完整性和准确性。非主属性通常关联着表中的业务逻辑和数据完整性规则。

    6.全码:

    全码(Super Key)在关系数据库中是指一个属性集合,这个集合中的属性组合可以唯一地标识表中的每一行记录。全码是一个更广泛的概念,包括了所有能唯一标识记录的属性组合,无论这些组合有多大或包含多少属性。

    全码的关键特征是:

    1. 唯一性:使用全码可以唯一地确定表中的每一行。
    2. 包容性:全码可以是简单的,比如仅包含一个属性的候选码,也可以是复杂的,包含多个属性的组合。全码不限于最小必要属性集合,所以一个表可能有多个全码。
    3. 超集:所有候选码都是全码,但并非所有全码都是候选码。换句话说,候选码是最小的全码,没有多余的属性。

    例如,假设有一个表,其候选码是“学号”。在这种情况下,“学号”本身是一个全码,但是任何包含“学号”的更大属性组合,比如“学号+姓名”、“学号+地址”等,也都是全码,因为它们同样可以唯一地标识表中的记录。

    总之,全码是一个宽泛的概念,它涵盖了所有可能的属性组合,只要这些组合能唯一地标识表中的记录。而在实际的数据库设计中,更倾向于使用最小的全码,即候选码,以减少数据冗余和提高效率。

    7.外码

     


    7.关系的三种类型:(这里我不太能理解***

     

    (1)   - 基本关系/基表: 实际存在的表,是存储数据的逻辑表示。

    2023/11/23补充

    在关系数据库理论中,基本关系或基本表是指实际存储在数据库中的表。这些表是数据库的物理组成部分,包含了存储的数据记录。基本关系是数据库中最基本的存储单位,它们代表了数据库的实际内容。

    基本关系的主要特点包括:

    1. 数据存储:基本关系实际存储了数据库中的数据。它们以表格的形式组织数据,其中每一行代表一个数据记录,每一列代表一个字段或属性。

    2. 结构化:基本关系遵循固定的结构,即预定义的列和数据类型。每个基本表都有其特定的结构,定义了存储在其中的数据的格式和类型。

    3. 物理实现:基本关系是关系数据库管理系统(RDBMS)中数据的物理实现。它们是实际存储在硬盘或其他存储介质上的表。

    4. 操作对象:数据库操作,如查询、更新、删除和插入操作,都是在基本关系上进行的。

    基本关系与理论上的“关系”概念有所区别。在数据库理论中,关系是一个抽象的数学概念,定义了数据应该如何组织和关联。而基本关系则是这个理论概念在实际数据库系统中的物理实现。简单来说,基本关系就是数据库中你实际看到和操作的表。

     举个例子:

    我们可以通过一个简单的例子来理解基本关系(基本表)的概念。

    假设有一个学校的数据库,其中有一个名为“学生”的基本关系(或基本表)。这个表的结构和一些示例数据可能如下所示:

    学号姓名年龄专业
    10001张三20计算机科学
    10002李四19物理学
    10003王五21化学

    在这个例子中,“学生”表是一个基本关系。它具有以下特点:

    1. 数据存储:表中存储了学生的具体信息,如学号、姓名、年龄和专业。

    2. 结构化:每一列(如学号、姓名、年龄、专业)都有固定的数据类型和含义。每一行代表一个学生的完整记录。

    3. 物理实现:这个表实际存在于数据库中,是数据库物理存储结构的一部分。

    4. 操作对象:数据库的操作,例如查询某个学生的信息、更新学生的年龄、添加新的学生记录或删除现有记录,都是直接针对这个“学生”表进行的。

    这个“学生”表就是一个典型的基本关系示例,展示了关系数据库中如何以表格形式存储和管理数据。



    (2)   - 查询表: 查询结果对应的表。

    查询表(Query Table)在关系数据库中是指通过查询操作(如 SQL 查询)产生的临时表。这些表不是数据库中永久存储的表,而是由特定查询语句的执行结果动态生成的。查询表通常用于表示复杂查询的结果,它们可以是基本表的数据的选取、投影、连接或其他操作的结果。

    查询表的主要特点包括:

    1. 动态生成:查询表是根据查询语句在运行时生成的。它们不是数据库的固定组成部分,而是根据需要临时创建的。

    2. 查询结果:查询表通常包含了一些基本表中的数据,这些数据是根据特定查询条件筛选和处理后的结果。

    3. 临时性:查询表的生命周期通常与查询操作本身相关联。一旦查询完成,查询表就会被丢弃,除非它被显式地保存或用于进一步的操作。

    4. 用途:查询表用于支持复杂的数据检索需求,如多表连接、数据过滤、排序等。

    例如,考虑以下 SQL 查询语句:

    1. SELECT 姓名, 专业
    2. FROM 学生
    3. WHERE 年龄 > 20;

    这个查询语句会生成一个查询表,包含了“学生”基本表中年龄大于20的所有学生的姓名和专业。这个查询表是临时的,只存在于查询执行的上下文中,用于展示查询结果。



    (3)   - 视图表: 由基本表或其他视图表导出的,是虚表,不对应实际存储的数据。

    2023/11/23

    视图表(简称视图)在关系数据库中是一个非常重要的概念。视图是基于数据库中一个或多个基本表(或其他视图)的查询结果,它像一个虚拟的表一样存在。视图本身不存储数据,它是一个数据库查询的结果集的抽象表示。

    视图的主要特点包括:

    1. 虚拟性:视图不直接存储数据,它们是基于基本表的查询操作的结果。当基本表中的数据发生变化时,视图中显示的数据也会相应变化。

    2. 查询基础:视图是由一个数据库查询语句定义的。这个查询可以简单(只从一个表中检索数据),也可以复杂(涉及多个表的连接、过滤和聚合)。

    3. 数据展示:视图可以用来展示数据的特定部分或以特定方式组织的数据,这对于简化复杂查询和增强数据安全性很有帮助。

    4. 更新:某些类型的视图是可更新的,这意味着可以通过视图来修改底层基本表的数据。但这依赖于视图的定义和数据库系统的限制。

    5. 安全性和简化操作:视图可以用于提供对数据的限制性访问,有助于保护敏感数据,并且通过隐藏复杂的SQL查询,使得用户更容易地访问和操作数据。

    例如,假设有一个包含学生详细信息的基本表,可以创建一个视图来展示仅包含学生的姓名和专业的信息。这个视图可以由以下类似的SQL语句创建:

    1. CREATE VIEW 学生简略信息 AS
    2. SELECT 姓名, 专业
    3. FROM 学生;

    2023/11/23补充

    8.两条限定和扩充

    (1)无限关系在数据库系统中是无意义的。因此,限定关系数据模型的关系必须是有限集合

    我的理解:

    在关系数据库模型中,关系是由行(元组)和列(属性)组成的表。当谈论到笛卡尔积和无限关系时,这里实际上涉及两个关键概念:关系的数学基础和数据库系统的实际应用。

    1. 笛卡尔积和交换律

      • 在集合论中,笛卡尔积是两个集合所有可能的有序对的集合。如果有集合 A 和集合 B,它们的笛卡尔积表示为 A×B。
      • 笛卡尔积不满足交换律,意味着 A×B 和 B×A 是不同的,因为产生的有序对元素的顺序不同。在关系数据库中,这对应于列的顺序,列的顺序改变了,表的结构也就改变了。
    2. 有限性的重要性

      • 在实际的数据库系统中,关系必须是有限的。这是因为数据库需要在有限的存储空间内存储数据,并且需要在合理的时间内对数据进行处理。
      • 如果关系是无限的,那么存储和处理这些数据将变得不切实际,甚至是不可能的。因此,实际应用的关系数据模型限制关系必须是有限集合。

    在数据库理论中,我们经常使用数学上的集合和关系概念来描述和理解数据库的结构和操作。然而,在实际的数据库设计和实现中,我们必须考虑到实际的物理和性能限制,这就是为什么数据库中的关系被限定为有限集合的原因。这确保了数据库系统既能有效地存储数据,也能在合理的时间内对数据进行操作和查询。

    (2)通过为关系上的每个列附加一个属性名的方法取消关系属性的有序性

    这句话描述的是关系数据库模型的一个重要特性:属性(列)的有序性对于数据的意义和操作是不重要的。在数学的关系概念中,元组(行)中的元素(即属性值)是有序的。但是,在关系数据库中,通过为每个列(属性)附加一个唯一的属性名来消除这种有序性的影响。

    这里的关键点是:

    1. 属性名的使用:在关系数据库中,每个属性(列)都有一个唯一的名称。这意味着你可以通过属性名来引用数据,而不是依赖于列的物理顺序。

    2. 取消有序性的影响:在数学中的关系(如笛卡尔积)是严格依赖于元素的顺序的,但在数据库中,列的物理排列顺序对于如何解释数据是不重要的。换句话说,无论列在表中的物理位置如何,列的含义和它所代表的数据都不会改变。

    3. 操作的便利性:这种设计使得在数据库操作(如 SQL 查询)中,可以更灵活地引用数据。例如,无论列在表中的实际顺序如何,查询语句可以按任意顺序引用这些列。

    4. 限定和扩充:这可以看作是对数学关系概念的一种扩充和限定。扩充在于它引入了属性名的概念,而限定在于它去除了元素顺序的重要性,使得模型更适合于实际的数据存储和操作。

    通过这种方式,关系数据库模型能够更加灵活和实用,使得数据库设计、数据存储和查询操作更加高效和直观。


    9. 关系的六条性质:


       - (1)列是同质的
       -(2)不同的列可以出自同域
       - (3)列的顺序无所谓,即列的顺序可以任意交换
       - (4)任意两个元组的候选码不能取相同的值
       - (5)行的顺序无所谓

       - (6)分量必须取原子值,即每个分量必须是不可分割的数据项
       
    4. **关系的规范化**:
       - 关系模型要求关系必须是规范化的。
       - 每一个分量都必须是不可分的数据项。
       - 规范化的关系简称为范式(Normal Form, NF)。

       - “表中有表”是不允许的。

    5. **例子**: 表2.3展示了导师与研究生之间的一对多关系,但由于`POSTGRADUATE`属性中的分量取了两个值,这不符合规范化的要求。

    6. **实际数据库产品的性质**: 不是所有的关系数据库产品都完全满足这6条性质。例如,有的仍然区分了属性顺序和元组的顺序。元组有时被称为记录。

    通过这些笔记,可以清晰地理解关系数据库的关键概念,特别是关于关系的性质和规范化的要求。

    2.1.2 关系模式

    1. 型与值的区分:在关系数据库中,关系模式代表“型”,而关系代表“值”。


    2023/11/23补充

    解释:

    这句话描述的是关系数据库中“型”和“值”的区分,这是关系数据库理论的一个基本概念。

    1. 型(Schema)

      • 在关系数据库中,“型”指的是关系模式(Relation Schema),它定义了表的结构。
      • 关系模式描述了表的框架,包括表中各列(属性)的名称和数据类型。例如,一个“学生”表的模式可能包括学号(整数)、姓名(字符串)和年龄(整数)等列。
      • 这相当于是表的蓝图或定义,指明了数据应该如何组织,但不包含具体的数据内容。
    2. 值(Instance)

      • 关系数据库中的“值”指的是关系(Relation),即在特定时刻,按照模式所存储的实际数据。
      • 这是表中的具体数据,例如某一时刻“学生”表中的所有学生记录。这些记录遵循关系模式的定义,但它们是动态变化的,随着数据的增加、删除和修改而改变。

    简单来说,型与值的区分是理解关系数据库结构的一个重要方面:

    • 型(Schema) 是静态的,定义了数据应该如何存储。
    • 值(Instance) 是动态的,表示在特定时间点上存储的实际数据。

    这种区分有助于理解数据库设计(定义数据的结构)和数据库操作(处理实际数据)之间的关系。

    我的理解:

    在我看来其实型就是数据定义的格式比如学生的表就应该包括学号姓名班级这些属性就组成了格式



    2. 关系模式描述:关系模式指明了元组集合的结构,如何由哪些属性构成,这些属性来自哪些域,以及它们之间的映像关系。
    3. 完整性约束:现实世界的事实和规则限定了关系模式所有可能的关系必须满足一定的完整性约束条件。


    我的理解:

    在关系数据库模型中,完整性约束是一组规则,用于确保数据库中的数据的准确性和可靠性。这些约束反映了现实世界的事实和业务规则,用以限制在数据库中可以存储的数据类型和范围。理解这个概念,可以从以下几个方面来看:

    完整性约束的种类

    1. 实体完整性

      • 这通常涉及主键。主键不能有空值,必须是唯一的,以确保每个记录都可以被唯一标识。
    2. 参照完整性

      • 涉及外键,确保一个表中的数据引用另一个表中的有效数据。例如,学生表中的班级编号必须在班级表中存在。
    3. 域完整性

      • 指定属性值的类型、格式、范围等。例如,学号可能必须是整数,年龄不能为负数等。
    4. 用户定义的完整性

      • 特定于业务规则的约束条件,例如,“学生的注册日期必须早于毕业日期”。

    完整性约束的作用

    • 保证数据的正确性和一致性:通过强制实施这些规则,数据库确保其内容反映现实世界的准确和合理的状态。
    • 防止错误数据的输入:完整性约束阻止了无效或不合适数据的输入,这对于维护数据库的质量至关重要。
    • 映射现实世界的规则:这些约束条件通常基于现实世界的逻辑和规则,确保数据库的结构和数据与现实世界保持一致。

    总的来说,这句话强调了在设计和维护关系数据库时,确保数据完整性的重要性。通过在关系模式中定义这些约束,数据库可以更准确地反映现实世界的复杂性和多样性,同时保持数据的准确性和可靠性。



    4. 定义2.4:关系模式(relation schema)形式化地表示为R(U,D,DOM,F)。

    R:关系名

    U:为组成该关系的属性名集合

    D:为U中属性所来自的域

    DOM:为属性向域的映像集合

    F:为属性间数据的依赖性集合
    5. 关系与关系模式的区别:关系模式是静态的描述,而关系是动态的,表示在某一时刻的状态或内容。

     

    2.1.3 关系数据库

    1. **关系的表示**:实体及其联系在关系模型中都用关系表示。
    2. **关系数据库的定义**:在特定应用领域中,所有关系的集合构成一个关系数据库。
    3. **关系数据库模式与值的区分**:关系数据库模式描述关系数据库,而关系数据库的值表示某一时刻的关系集合。

    2.1.4 关系模型的存储结构

    1. **逻辑与物理表示**:关系数据的逻辑模型是表,而物理组织可以依赖于操作系统或由关系数据库管理系统自行管理。

     总结:

    当谈及关系数据结构,我们通常是指关系数据模型的核心组件。关系数据模型由E.F.Codd在1970年提出,它为数据管理提供了一种逻辑方法,基于数学的集合论和逻辑。以下是关系数据结构的关键概念及其形式化定义的简要总结:

    1. **关系**:关系是由相同类型的元组(或行)组成的集合。每个元组是由一组有序的属性值组成。

    2. **属性**:每个关系都有一个固定数目的属性,可以视为关系的列。每个属性都有一个相关联的域,该域规定了该属性可能的值的集合。

    3. **域**:域是一个属性可能取的值的集合。比如,日期域包含了所有可能的日期。

    4. **元组**:在关系中,元组代表了一行数据。每个元组都包含该关系的每个属性的一个值。

    5. **关系模式**:描述了关系的结构。它可以形式化地表示为:  
       \[ R(A_1, A_2, ..., A_n) \]
       其中,\( R \) 是关系名,而 \( A_1, A_2, ..., A_n \) 是属性名。

    6. **关系实例**:是关系模式在某一时刻的状态或值。它是元组的集合。

    7. **完整性约束**:这是关系数据库必须满足的条件,确保数据的准确性和可靠性。常见的约束包括实体完整性(确保主键的唯一性和非空性)和参照完整性(确保外键值匹配另一个表中的主键值或为空)。

    8. **主键**:是关系中唯一标识元组的属性集。在关系的任何两个不同的元组中,主键的值都是不同的。

    关系数据结构的美妙之处在于它的数学基础。它基于集合论,并使用标准的数学记号进行操作,如并集、交集和差集。这种结构为数据库管理提供了一个坚实的理论基础,使得数据操作和查询都可以在一个清晰、一致的框架内进行。

  • 相关阅读:
    基于单向链表结构的软件虚拟定时器的设计与构建
    手把手教你定位线上MySQL锁超时问题,包教包会
    基于Python+DenseNet121算法模型实现一个图像分类识别系统案例
    Mysql 中令人稀里糊涂的Explain
    【集群迁移】使用Shell脚本获取老集群整个Hive库的建库、建表DDL
    vue组件传值
    day03-拉取在线用户&无异常退出功能
    动态内存管理(malloc free calloc realloc)
    我们拆了一款双通道三核便携示波器
    wx小程序-input事件改变数据
  • 原文地址:https://blog.csdn.net/tang7mj/article/details/133691224